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Foreword 



This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet 

converged Services and Protocols for Advanced Networking (TISPAN) and originally published as 

ETSI TS 183 010 [7]. It was transferred to the 3"* Generation Partnership Project (3GPP) in December 2007. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage three Protocol Description of the Communication Hold (HOLD) services, 
based on stages one and two of the ISDN Hold (HOLD) supplementary services. It provides the protocol details in the 
IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session 
Description Protocol (SDP). 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the HOLD supplementary service. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[2] Void. 

[3] Void 

[4] IETF RFC 3264 (2002): "An Offer/ Answer Model with the Session Description Protocol (SDP)". 

[5] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 

and supplementary services; Stage 1". 

[6] 3GPP TS 24.628: "Common Basic Communication procedures; Protocol specification". 

[7] ETSI TS 183 010 VI. 2. 2: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Signalling Control Protocol; Communication HOLD 
(HOLD) PSTN/ISDN simulation services; Protocol specification". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [5] apply. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACR/CB Anonymous Communication Rejection and Communication Barring 

AS SIP Application Server 

CDIV Communication Diversion 

CSCF Call Session Control Function 

ECT Explicit Communication Transfer 
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HOLD communication session HOLD 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Digital Network 

MCID Malicious Communication IDentification 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy-CSCF 

PSTN Public Switched Telephone Network 

S-CSCF Serving-CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

UE User Equipment 



Communication Hold (HOLD) 



4.1 



Void 



4.2 Description 
4.2.1 General description 

The Communication Hold supplementary service enables a user to suspend the reception of media stream(s) of an 
established IP multimedia session, and resume the media stream(s) at a later time. 

4.3 Operational requirements 



4.3.1 



Provision/withdrawal 



The HOLD service that includes announcements shall be provided after prior arrangement with the service provider. 

4.3.2 Requirements on the originating network side 

No specific requirements are needed in the network. 

4.3.3 Requirements in the network 

No specific requirements are needed in the network. 

4.3.4 Requirements on the terminating network side 

No specific requirements are needed in the network. 

4.4 Coding requirements 

No specific coding requirements are needed. 
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4.5 Signalling requirements 
4.5.1 Activation/deactivation 

The HOLD service is activated at provisioning and deactivated at withdrawal. 

4.5.1 A Registration/erasure 

The HOLD service requires no registration. Erasure is not applicable. 

4.5.1 B Interrogation 

Interrogation of HOLD is not applicable. 

4.5.2 Invocation and operation 
4.5.2.1 Actions at the invoking UE 

In addition to the application of procedures according to 3GPP TS 24.229 [1] , the following procedures shall be applied 
at the invoking UE in accordance with RFC 3264 [4]. 

A UE shall not invoke the HOLD service on a dialog associated with an emergency call the UE has initiated. 

If individual media streams are affected, the invoking UE shall generate a new SDP offer where: 

for each media stream that is to be held, the SDP offer that contains: 

an "inactive" SDP attribute if the stream was previously set to "recvonly" media stream; or 

a "sendonly" SDP attribute if the stream was previously set to "sendrecv" media stream; 

for each media stream that is to be resumed, the SDP offer contains: 

a "recvonly" SDP attribute if the stream was previously an inactive media stream; or 

a "sendrecv" SDP attribute if the stream was previously a sendonly media stream, or the attribute may be 
omitted, since sendrecv is the default; or 

for each media stream that is unaffected, the media parameters in the SDP offer remain unchanged from the 
previous SDP offer. 

If all the media streams are to be held, the invoking UE shall generate an SDP offer containing a session level 
direction attribute, or separate media level direction attributes, in the SDP that is set to: 

"inactive" if the streams were previously set to "recvonly" media streams; or 

"sendonly" if the streams were previously set to "sendrecv" media streams; or 

If all the media streams that shall be resumed, the invoking UE shall generate a session level direction attribute, or 
separate media level direction attributes, in the SDP that is set to: 

"recvonly" if the streams were previously inactive media streams; or 

"sendrecv" if the streams were previously sendonly media streams, or the attribute may be omitted, since 
sendrecv is the default. 

Then the UE shall send the generated SDP offer in a re-INVITE request (or UPDATE request) to the remote UE. 
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4.5.2.2 Void 

4.5.2.3 Void 

4.5.2.4 Actions at the AS of the invoking UE 

As a network option, the AS of the invoking UE shall for each media stream marked "recvonly" lower the bandwidth by 
setting the "b=AS:" parameter to a small value, e.g. "b=AS:0". The "b=RR:" and "b=RS:" parameters shall be set to 
values large enough to enable continuation of the RTCP flow, e.g. "b=RR:800" and "b=RS:800". 

As a network option, the AS of the invoking UE shall initiate the procedures for the provision of an announcement to 
the held user in accordance with 3GPP TS 24.628 [6]. 

4.5.2.5 Void 

4.5.2.6 Void 

4.5.2.7 Void 

4.5.2.8 Void 

4.5.2.9 Actions at the held UE 

3GPP TS 24.229 [1] shall apply. 

4.6 Interaction with other services 

4.6.1 Communication Hold (HOLD) 

Not applicable. 

4.6.2 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.3 Terminating Identification Restriction (TIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.4 Originating Identification Presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.5 Originating identification restriction (OIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.6 Conference calling (CONF) 

If a participant of a conference invokes the HOLD service, it is not desirable to provide an announcement to the 
conference. If the AS supporting the HOLD supplementary service receives a re-IN VITE (or UPDATE) request which 
includes the "isfocus" feature parameter in the Contact header, the AS shall not initiate the procedures for the provision 
of an announcement to the held user(s). 



£75/ 



3GPP TS 24.61 version 8.5.0 Release 8 1 ETSI TS 1 24 61 V8.5.0 (201 3-01 ) 

4.6.7 Communication Diversion services (CDIV) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.8 Malicious Communication IDentification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.9 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.1 Explicit Communication Transfer (ECT) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.7 Interactions with other networks 

4.7.1 Void 

4.7.2 Void 

4.7.3 Void 

4.8 Parameter values (timers) 

Not applicable. 
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Annex A (informative): 
Signalling Flows 

A.1 HOLD communication 

Assumption is that a session has been estabHshed between UE-A and UE-B using basic communication procedures 
according to 3GPP TS 24.229 [1], therefore the following signalling flows do not apply to the initial INVITE. 

A.1 .1 HOLD communication without announcement 

The following diagram shows a communication session put on hold using a re-INVITE request . The same can be 
achieved by sending an UPDATE request. 



UE-A 



P-CSCF 
A 



S-CSCF 



1. INVITE 
(sendonly) 



8. 200 OK 
(recvonly) 

— 9. ACK— 



2. INVITE 
(sendonly) 



7. 200 OK 
(recvonly) 



-10. ACK- 



AS 



• RTP. 



3. INVITE 
(sendonly) 



6. 200 OK 
(recvonly) 



-11. ACK- 



P-CSCF 
B 



4. INVITE 
(sendonly) 

5. 200 OK 
(recvonly) 



-12ACK- 



UE:B 



no RTP sent 



Figure A.1 .1 .1 : HOLD communication witliout announcement to thie hield user 

1. UE-A sends a re- INVITE to UE-B to hold the session - see example in table A.1. 1.1-1. Hold is done by changing 
the SDP attribute. For each media stream that shall be held: 

"a=sendonly", if the stream was previously a sendrecv media stream; 

"a=inactive", if the stream was previously a recvonly media stream. 

Table A.1.1.1-1: re-INVITE request (UE to P-CSCF) 



INVITE user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 
;comp=sigcomp SIP/2.0 
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via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp>;+g. 3gpp . icsi-ref ="urn%3 Aurn- 7% 3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVPF 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos none remote sendonly 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVPF 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos none remote sendonly 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 
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A.1 .2 HOLD communication with announcement 

The following diagram shows a communication session put on hold using a r-elNVITE reques with an announcement 
being played by the AS to the held party.tThe same can be achieved by sending an UPDATE request. 
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Figure A.1 .2.1 : HOLD communication with announcement to the held user 

1. UE-A sends an INVITE to UE-B to hold the session - see example in table A.1. 2. 1-1. Hold is done by changing 
the SDP attribute. For each media stream that shall be held: 

"a=sendonly", if the stream was previously a sendrecv media stream; 

"a=inactive", if the stream was previously a recvonly media stream. 

Table A.1.2.1-1: re-INVITE request (UE to P-CSCF) 



INVITE user2_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 
;comp=sigcomp SIP/2.0 
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via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp>;+g. 3gpp . icsi-ref ="urn%3 Aurn- 7% 3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVPF 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos none remote sendonly 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVPF 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendonly 

a=des:qos none remote sendonly 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 
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A.1 .3 HOLD communication with modification of the SDP answer 

The following diagram shows a communication session put on hold using a re-INVITE request with an announcement 
being played by the AS to the held party. The same can be achieved by sending an UPDATE request. 
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Figure A.1.3.1: HOLD communication with modification of the SDP answer 

1 . UE-A sends an INVITE request to UE-B to hold the session by changing the direction attribute to 
"a=sendonly". 



Table A.I. 3-1 : re-INVITE request (UE to P-CSCF) 



INVITE user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 
;comp=sigcomp SIP/2.0 
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via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-212-555-2222>; tag=24615 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-9S ; spi-c=987S5432 ; spi-s=87S54321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6 

;comp=sigcomp>;+g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVPF 98 99 

b=AS:75 

a=sendonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVPF 97 96 

b=AS:25 .4 

a=sendonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



10. The AS modifies the bandwidth attribute in the 200 (OK) response. 
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Table A.I. 3-2: 200 (OK) response (AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bkl20f 34 . 1 
Via: SIP/2. 0/UDP 1.2 .3 .4 :1357;branch=z9hG4bKnashds7 
From: <sip :userl_publicl@homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222>; tag=24615 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8^5 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 128 INVITE 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVPF 98 99 

b=AS : 

b=RS:800 

b=RR:2400 

a=recvonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVPF 97 96 

b=AS : 

b=RS:800 

b=RR:800 

a=recvonly 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



A.2 RESUME Communication 

A.2.1 RESUIVIE communication without announcement 

The following diagram shows how a communication session is resumed using a re-INVITE request; The same can be 
achieved by sending an UPDATE request. 
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Figure A.2.1 .1 : RESUME communication without announcement to the held user 

1. UE-A sends an INVITE to UE-B to resume the session - see example in table A.2.1. 1-1. Resume is done by 
changing the SDP attribute. For each media stream that shall be resumed: 

"a=sendrecv", if the stream was previously a recvonly media stream, or the attribute can be omitted, since 
sendrecv is the default; 

"a=recvonly", if the stream was previously an inactive media stream. 

Table A.2.1.1-1: re-INVITE request (UE to P-CSCF) 



INVITE user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 
To: <tel:+l-212-555-2222> 
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Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp>;+g. 3gpp . icsi-ref ="urn%3 Aurn- 7% 3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVPF 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 



A.2.2 RESUME communication with announcement 

The following diagram shows how a communication session is resumed using a re-INVITE request after it was held 
with an announcement being played by the AS to the held party.The same can be achieved by sending an UPDATE 
request. 



£75/ 



3GPP TS 24.610 version 8.5.0 Release 8 



20 



ETSI TS 124 610 V8.5.0 (2013-01) 



UE-A 



P-CSCF 
A 



S-CSCF 



1. INVITE 
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Figure A.2.2.1 : RESUME communication with announcement to the held user 

1. UE-A sends an INVITE to UE-B to resume the session - see example in table A.2.2.1-1. Resume is done by 
changing the SDP attribute. For each media stream that shall be resumed: 

"a=sendrecv", if the stream was previously a recvonly media stream, or the attribute can be omitted, since 
sendrecv is the default; 

"a=recvonly", if the stream was previously an inactive media stream. 

Table A.2.2.1-1 : re-INVITE request (UE to P-CSCF) 



INVITE user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad7Scc7f c74 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 7 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:orig@scscf 1 .homel .net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 
To: <tel:+l-212-555-2222> 
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Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp>;+g. 3gpp . icsi_ref ="urn%3 Aurn- 7% 3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVPF 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 
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